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Introduction 

A  major  advance  toward  a  useable  programming  calculus  has  been  made  by 
Dijkstra  [1,2].  His  syntactic  tool  is  "guarded  command  sets",  from  which  he 
constructs  an  alternative,  or  IF,  statement,  and  a  repetitive,  or  DO,  state¬ 
ment.  His  semantic  tool  is  "predicate  transformers",  which  specify,  for  a 
given  statement  S  and  post-condition  if,  the  weakest  pre-condition 
guaranteeing  that  S  will  establish  if.  In  this  paper,  we  shall  assume  that 
the  reader  is  familiar  with  the  above. 

Our  purpose  is  to  offer  some  constructive  criticisms  of  Dijkstra' s 
approach.  In  particular,  we  challenge  the  utility  of  the  repetitive  DO 
statement,  and  offer,  in  its  place,  the  notion  of  recursive  refinement. 

Before  the  reader  flees  in  panic  from  the  "sledgehammer"  tactics  of  replacing 
something  as  simple  as  repetition  by  something  as  complicated  as  recursion, 
let  us  make  our  motivation  plain.  The  semantics  of  DO  involve  a  recurrence 
relation  on  the  semantics  of  IF;  that  is  by  far  the  most  complicated  part  of 
Dijkstra' s  rudimentary  language.  Our  purpose  is  to  avoid  complication  as 
much  as  possible.  By  contrast,  we  shall  claim  that  recursive  refinement 
introduces  less  semantic  complication  to  the  language.  Even  more  important, 
we  shall  claim  that  programs  composed  using  recursive  refinement  are  simpler 
and  clearer  than  programs  composed  of  DO  statements.  To  support  this  claim, 
we  shall  present  some  of  the  programming  examples  of  [1].  It  is  intended 
that  our  programs  be  compared  with  those  in  [1].  For  the  reader's  con¬ 
venience,  we  include  the  latter  in  an  appendix,  but  we  suggest  that  the 
reader  refer  instead  to  [1],  which  contains  a  charming  and  illuminating 


commentary 
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The  Language 

For  our  programming  language,  we  mainly  adopt  Dijkstra's  notations. 

The  empty  statement  will  be  denoted  by  " skip ".  An  assignment  will  be 

denoted  by  "x:-E"  where  x  is  any  identifier,  and  E  is  any  expression. 

Composition  (sequencing)  of  statements  <Sj  and  S2  is  denoted  by  "5i;52". 

The  alternative,  or  IF,  statement  is  denoted  by 

if  Bi+SlAbz+SLz  1  . ..  !b  -+SL  fi 
—  n  n  — 

where  the  B .  are  boolean  expressions,  and  the  SL .  are  statement  lists. 

Z  z 

Like  Dijkstra,  we  shall  not  make  use  of  the  "abort"  statement.  Unlike 
Dijkstra,  we  shall  not  make  use  of  the  repetitive,  or  DO  statement. 


The  programming  technique  known  as  "stepwise  refinement",  championed  by 
Dijkstra  [3]  and  others  [4],  has  been  used  to  great  advantage  in  [1].  It 
involves  the  invention  of  a  name  for  a  portion  of  a  program,  using  the  name 
in  place  of  the  program  portion,  and  specifying  the  text  of  the  program 
portion  elsewhere  (possibly  re-using  the  technique  within  the  text  of  the 
program  portion) .  We  shall  refer  to  the  use  of  a  name  in  place  of  some 
statements  as  a  "call",  and  we  shall  refer  to  the  specification  of  the 
statements  as  a  "refinement".  Thus,  in  Dijkstra’s  notation,  a  program  may 
consist  of  the  two  calls 


"action  A";  "action  B" 
together  with  the  refinements 

"action  A":  (statement  list) 


and 


"action  B":  (statement  list) 

Refinement  is  commonly  considered  to  be  an  extra-language  programming  technique, 
as  in  [1];  the  programmer  is  then  required  to  assemble  the  various  pieces  of 
his  program  into  their  proper  places  to  form  the  final  product.  We  shall  add 
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the  call  and  refinement  statements  to  Dljkstra's  little  language;  we  thus 
save  the  programmer  from  what,  in  many  cases,  is  a  purely  clerical  task, 
and  we  allow  the  final  program  to  retain  the  intermediate  design  decisions. 
This  is  our  only  addition  to  the  language.  Since  we  have  made  it,  allowing 
recursive  calls  does  not  make  the  language  larger;  on  the  contrary, 
disallowing  them  would  require  a  special  rule. 

Note.  Although  we  have  used  the  word  "call",  we  urge  the  reader  not 
to  condemn  our  addition  to  the  language  because  of  some  inefficient 
implementation  of  procedure  calls  in  some  other  language.  We  do  not 
intend  to  imply  anything  about  the  implementation,  in  particular, 
whether  a  refinement  is  compiled  "out-of-line"  with  branching  to  and 
from  it,  or  "in-line"  in  place  of  the  call.  We  especially  do  not 
intend  to  imply  stacking  activity.  We  shall  discuss  implementation 
later.  ( End  of  note,) 


# 
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Semantics 

The  meaning  of  the  statements  in  our  language  may  be  given  in  either  of 
two  ways.  One  is  called  "operational  semantics";  in  this  view,  a  statement 
is  a  command  to  change  state  (the  state  is  a  list  of  variables  together  with 
their  values)  from  a  given  initial  state  to  one  of  the  desired  final  states. 

(As  Dijkstra  points  out,  the  word  "command"  would  have  been  preferable  to 
"statement".)  The  operational  semantics  of  a  statement  are  instructions  on 
how  to  execute  the  statement  (perform  the  change  in  state).  The  other  way  of 
giving  the  meaning  of  a  statement  is  called  "mathematical  semantics";  in  this 
view,  a  statement  describes  a  change  in  state  (it  is  not  a  command  to  do 
anything) .  The  description  is  less  detailed  than  a  complete  mapping  between 
initial  and  final  states,  for  that  would  be  equivalent  to  a  set  of  instructions 
for  changing  the  state.  Instead,  it  is  a  mapping  between  sets  of  initial 
states  and  sets  of  final  states.  A  set  of  states  is  characterized  by  a 
predicate  on  the  program  variables,  thus  the  mathematical  semantics  of  a 
statement  are  given  as  a  predicate  transformer. 

Operational  semantics  are  necessary  for  the  implementation,  or  execution, 
of  programs.  But  for  programming,  or  understanding  programs,  they  are  too 
detailed.  Since  our  interest  in  this  paper  is  mainly  programming,  we  shall 
shun  operational  semantics,  and  embrace  mathematical  semantics.  In  this 
respect,  we  follow  Dijkstra  [1]  and  many  others  [6,7,8].  Perhaps  partly  as  a 
concession  to  our  history  of  trying  to  understand  programs  by  tracing  their 
executions,  Dijkstra  gives  both  the  operational  and  mathematical  semantics  of 
the  statements  he  introduces.  Unfortunately,  the  terminology  of  the  text 
comes  largely  from  the  operational  view,  such  as  "control  goes  through  the 
loop"  [1,  p.66],  and  "repetitive  construct"  or  "repetition"  [1,  throughout]. 
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Recognizing  that  programming  is  a  goal-directed  activity,  Dijkstra  gives 

the  semantics  of  a  statement  S  by  a  predicate  transformer  vp  that  tells  us, 

for  any  post-condition  Rt  the  weakest  pre-condition  such  that  S  establishes 

R.  This  is  denoted  by  "wpOS,  R)" .  The  semantics  of  our  chosen  statements  are 

defined  as  satisfying  the  following  equations. 

wp ("skip",  R)  =  R 

wp("x:»£",  R)  -  R  _ 
r  *  x:bE 

wp("51;52",  R)  =  wp (£1 ,  wp(52,  R)) 

wp(IF,  R)  ■  (  j  and  (V  i:B.  wp (SL.t  R)) 

'V  "  %  %> 

In  the  above,  "/?  ,  denotes  the  predicate  obtained  from  R  by  simultaneously 

cc  •  hi 

changing  all  occurrences  of  "x"  into  "E" .  The  existential  and  universal 
quantifiers  take  i  over  the  integers  in  the  range  lzi*n. 

The  call  and  refinement  statements  give  us  no  new  semantic  equations.  A 
call  is  given  meaning  by  the  details  of  its  refinement.  The  act  of  naming 
some  statements,  and  using  the  name  in  their  place,  is  not  semantically 
significant.  This  remains  true  even  if  some  of  the  calls  are  recursive.  In 
this  case,  however,  the  equations  become  recursive,  raising  the  possibility 
that  they  may  have  more  than  one  solution.  To  specify  a  particular  solution, 
we  define  wp (5,  R)  as  the  strongest  predicate  satisfying  the  equations. 
Solving  the  equations  may  be  difficult,  with  or  without  recursion;  sometimes 
the  solution  may  be  expressed  in  a  "closed  form",  and  sometimes  not  (see  the 
section  titled  "Solving  the  Semantic  Equations").  Fortunately,  as  Dijkstra 
points  out  [1,  p.17],  we  are  not  very  interested  in  solving  the  equations. 

For  programming,  a  predicate  that  is  stronger  than  wp  (and  hence  not  a 
solution)  will  content  us. 
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Problem  Solving  Methods 

We  now  present  three  problem  solving  methods.  The  first  may  be  called 
"divide  and  conquer".  We  want  to  establish  R.  If  we  cannot  see  how  to 
do  so  directly,  but  we  see  that  the  conjunction  of  predicates  P  and  Q 
implies  B,  then  the  refinement 

"establish  B" : 

"establish  P"; 

"maintain  P,  establish  Q " 

will  do  the  job.  In  the  second  call,  predicate  P  is  called  an  invariant. 
Clearly  we  can  generalize  to  several  subgoals. 

The  second  problem  solving  method  is  "case  analysis".  Suppose  we  can 
find  n  predicates,  B i,  B2 ,  •••»  #n>  such  that  at  least  one  must  be  true, 
and  for  each  £,  given  B ^  we  can  establish  R.  Our  refinement  is  then 

"establish  P": 

i f_  -►  "given  Bj,  establish  B" 

fl  B2  -*•  "given  B2,  establish  P" 

^  B  -*■  "given  B  ,  establish  B" 
n  n * 

fi 

In  each  alternative  we  are,  of  course,  free  to  establish  subgoals  and  do 
further  case  analyses. 

Suppose  that,  even  with  these  methods,  we  do  not  see  how  to  refine 
"given  B^, establish  B"  for  some  alternative.  Then  the  third  problem  solving 
method  may  help.  It  is  to  delegate  the  task  to  a  refinement  after  making 
some  measurable  progress  toward  the  goal.  "Measurable  progress"  is  defined, 
as  in  [1],  as  a  decrease  in  a  monotonically  decreasing  integer-valued 
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function  that  is  bounded  below  (or  equivalently,  an  increase  in  a  monotonically 
increasing  integer-valued  function  that  is  bounded  above).  After  that,  the 
task  may  be  delegated  either  to  a  new  refinement,  or  to  the  current  refine¬ 
ment.  For  example,  if  t  is  the  aforementioned  function,  the  refinement  may  be 

"establish  if": 
if  ... 

Gfl.  -*■  "decrease  t" ;  "establish  i?" 

a... 

fi 

Having  seen  the  method,  we  are  now  tempted  to  not  bother  with  "decrease  i", 
and  to  simply  delegate  the  whole  alternative  to  "establish  if".  The  futility 
of  this  attempt  can  be  seen  from  the  equation  for  wp ("establish  if",  if):  the 
strongest  solution  implies  non  B..  Thus  the  shortcut  "works"  only  in  alterna- 
tives  that  are  unnecessary  anyway!  (For  proof,  and  for  an  illustration  that 
measurable  progress  is  sufficient  for  recursion,  see  the  section  titled 
"Solving  the  Semantic  Equations".)  After  making  measurable  progress,  one  need 
not  even  be  aware  of  using  recursion;  this  is  fortunate,  since  an  indirect 
recursion  may  escape  notice. 

The  three  programming  techniques  we  have  presented  are  not  the  only 
valuable  problem  solving  methods,  nor  are  they  sufficient  for  all  occasions. 

But  they  are  sufficient  to  begin  our  programming  examples. 
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Example  1 

(Euclid's  algorithm)  [1,  ch.7]  Given  two  positive  integers  X  and  X  , 
print  their  greatest  common  divisor.  Our  program  is  as  follows. 

x:=X;  y:*?; 

"print  GCD (x,y)" 
with  the  refinement 

"print  GCD (x,y)"  : 

if  xmy  -+■  print  (x) 

D  x>y  -*■  x:»x-y;  "print  GCD  (a:,:/)" 

0  x<y  -*  y:my-x;  "print  GCD(x,y)" 
fi 

Here  we  have  used  all  three  problem  solving  methods.  In  the  case  analysis, 
the  method  of  achieving  the  result  in  each  alternative  is  independent  of  the 
methods  used  in  the  other  alternatives.  In  the  first  alternative,  we  achieved 
our  result  directly;  in  the  other  two,  we  made  measurable  progress,  then  recursed. 

As  programmers,  we  may  comfortably  use  a  result  that  has  been  proved  with¬ 
out  being  constantly  aware  of  the  proof's  details.  But  for  those  who  want  to 
prove  for  each  program  separately  that  measurable  progress  is  sufficient  for 
recursion,  we  have  some  words  of  warning.  The  proof  is,  of  course,  an  induction 
on  the  measure  of  progress.  It  is  often  easy  to  see  that  a  recursive  construct 
works  for  n»0,  and  that  if  it  works  for  n*»fe-7,  it  will  work  for  n=fc.  The 
common  mistake  is  asking  (or  explaining)  how  it  works  for  n=*k-l  .  This 
mistake  is  made  for  one  of  two  reasons:  (a)  failure  to  assume  the  inductive 
hypothesis;  induction  requires  that  we  prove  an  implication,  not  the  hypothesis 
of  the  implication.  (b)  curiosity  about  the  implementation;  an  explanation  of 
the  implementation  should  come  only  after  the  semantics  are  understood,  not  as 
an  explanation  of  the  semantics.  For  either  reason,  this  mistake  leads  to  an 


effort  to  understand  by  tracing,  and  to  the  poor  man's  induction:  "If  it 
works  for  n=l ,  2,  and  3,  then  that's  good  enough  for  me.". 


10 


To  make  our  presentation  of  Euclid's  algorithm  more  formal,  we  shall  omit 
the  printing;  the  problem  is  to  establish 

R:  x=GCD(Y,Y) 

Our  invariant  is 


P:  x>0  and  y>0  and  GCD(x,2/)  =  GCD(Y,Y) 

Our  integer-valued  monotonically  decreasing  function  is 

t:  x+y 

The  invariant  P  implies  that  t  is  bounded  below.  We  shall  write  predicates 
whose  truth  has  been  established  as  comments  enclosed  in  braces. 

x:=X;  y:=Y;  {P} 

"maintain  P,  establish  x=*y"  {P} 

"maintain  P,  establish  x=z/": 

if  x=y  -*■  skip  {P  is  maintained,  x=y  is  established} 

1  x>y  -*■  x:=x-y;  {P  is  maintained,  t  is  decreased} 

"maintain  P,  establish  x=y"  { P  is  maintained, 

x=y  is  established} 

0  x>y  -*■  {P  is  maintained,  t  is  decreased} 

"maintain  P,  establish  x=y"  {P  is  maintained, 

x-y  is  established } 


fi 


Following  a  DO  construct,  one  is  entitled  to  conclude  that  all  guards 
are  false.  To  put  it  more  positively,  one  is  entitled  to  conclude  that  the 
"missing  guard"  is  true.  The  IF  is  more  straightforward:  the  conclusion  is 
established  explicitly  by  each  alternative.  But  then,  the  fact  that  IF  has 
simpler  semantics  than  DO  was  never  in  question;  our  point  is  that  the  re¬ 


cursive  aspect  is  irrelevant  to  the  predicate  transformations. 
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Example  2 

[1,  p.57.  Ex. 3]  Given  integers  a^O  and  d>0  establish 

R:  Ozr<d  and  d | ( a-r ) 

using  only  addition  and  subtraction.  We  obtain  an  invariant  by  weakening 
7?  to  the  more  easily  established 

P:  0<r  and  d  \  (a-r) 

Our  program  is 

r:=a;  {P} 

"maintain  P,  establish  r<d"  {P} 

At  this  point,  using  DO,  one  would  require  an  inspiration  as  expressed  by  the 
phrase  "it  is  hard  to  see  how  R  can  be  established  without  a  loop"  ll  p . 53 J . 
We  are  unable  to  eliminate  the  need  for  inspiration,  but,  in  the  spirit  of  the 
programming  calculus,  we  would  like  to  minimise  the  need  for  it.  With  our 
method,  one  needs  the  inspiration  at  this  point  to  use  case  analysis 

"maintain  P,  establish  r<d"  • 
if  r<d  -*■  skip 
0  rzd  ->  . . . 
fi 

but  one  need  not  realise  until  the  second  alternative  that  recursion  will  be 
needed.  Thus  we  have  broken  the  required  inspiration  into  two  pieces.  Choos¬ 
ing  r  as  our  measure  of  progress,  the  second  alternative  becomes 
"maintain  P,  decrease  r"j  "maintain  P,  establish  r<d" 

On  the  other  hand,  our  method  requires  that  the  program  portion  on  which 
we  recurse  be  named,  whereas,  if  we  use  DO,  there  is  no  such  necessity.  We 
introduced  the  refinement  as  a  freedom,  to  be  used  for  better  programming; 
but  now  that  it  is  seen  to  be  a  necessity,  it  may  seem  to  be  an  unfortunate 
burden.  Perhaps  so;our  rebuttal  is  that  the  names  add  understandability .  The 


issue  is  debatable 
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The  easiest  refinement  of  "maintain  P,  decrease  r"  is  simply  "n^r-d". 
However,  following  Dijkstra,  we  can  speed  up  our  program  by  introducing 
variable  dd,  and  maintaining  it  as  a  multiple  of  d.  Thus  we  can  decrease  r 
by  multiples  of  d  at  a  time. 

"maintain  P,  decrease  r": 
dd:*d;  {P  and  d\dd] 

"maintain  P  and  d\dd ,  decrease  r" 

"maintain  P  and  d\dd,  decrease  r": 
if  r<dd  •*  skip 
0  -*■  r:=r-dd;  dd:=dd+dd; 

"maintain  P  and  decrease  r " 

fi 

We  thus  obtain  a  program  that  is  computationally  equivalent  to  Dijkstra* s. 

But  now,  and  in  the  examples  to  follow,  we  would  like  to  show  that  our  methods 
can  do  better  than  merely  duplicate  what  is  attainable  with  DO. 

The  major  deficiency  in  the  last  refinement  above  is  that  it  does  not 
clearly  achieve  its  purpose.  It  is  obliged  to  decrease  r;  to  see  that  it 
does  so,  we  must  see  that  the  call  occurs  in  a  context  such  that  rid 
and  d=*dd.  Hence  the  alternative  guarded  by  ridd  will  be  selected.  The 
minor  deficiency  is  that,  since  we  know  r  ^dd,  a  test  is  made  unnecessarily. 

In  "loop"  terminology,  the  DO  construct  is  a  generalization  of  the 
"while ...  do ..." ;  the  test  is  at  the  beginning.  What  is  needed  is  a 
"repeat . . . until . . . " ;  using  DO  we  are  obliged  either  to  duplicate  some  code 
or  to  make  an  unnecessary  test.  Instead  of  mechanically  translating 
Dijkstra’ s  program,  we  should  have  written 
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"maintain  P  and  d\dd,  decrease  r": 
r:=r-dd;  dd : °dd+dd ; 
if  r<dd  ->  skip 

0  -*•  "maintain  P  and  d\dd,  decrease  r" 

fi 

It  is  now  clear,  without  examining  any  external  context,  that  the  refinement 


does  decrease  r*. 
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Example  3 

[1,  p.65.  Ex. 6]  Given  integers  X>1  and  Y^Q  establish 
R:  z -X* 

without  using  exponentiation.  As  before,  we  obtain  an  invariant  by  weaken¬ 
ing  R  to  something  that  is  more  easily  established. 

P:  zita?-/  and  y^O 
The  program  is  then 

x:-Xi  y:mX;  z:»2;  {P} 

"maintain  P,  establish  ym0"  {P} 
with  the  refinement 

"maintain  P,  establish  ym0"\ 
if  y=0  ->  skip 

0  y>0  -*■  "maintain  P,  decrease  y”; 

"maintain  P,  establish  ym0" 
fi 

Rote  1 .  The  condition  y^O  was  omitted  in  the  invariant  in  [1],  but  is 
required  so  that  a  decrease  in  y  will  be  measurable  progress.  ( End  of 
note  2 . ) 

Note  2.  Following  Dijkstra's  advice,  that  "all  other  things  being  equal, 
we  should  choose  our  guards  as  weak  as  possible"  [1,  p.57],  I  had 
originally  written  the  second  guard  above  as  "yfO".  In  Dijkstra's 
program,  using  DO,  the  guard  is  "ytO".  One  reason  is  robustness.  Suppose 
that,  due  to  either  machine  malfunction  or  incorrect  programming,  the 
portion  of  the  program  that  is  Intended  to  "maintain  P,  decrease  y "  should 
fail  to  maintain  P  by  decreasing  y  below  0 .  The  guard  " y>0 "  would  lead  to 
termination  of  the  DO  loop,  giving  no  alarm,  whereas  the  guard  would 

lead  to  non-termination.  The  latter  is  a  kind  of  alarm,  and  therefore  prefer¬ 
able.  In  our  program,  using  recursive  refinement,  the  guard  wouid  also 
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lead  to  non-termination,  should  y  be  erroneously  decreased  below  0.  But 
the  invariant  P  tells  us  that  we  need  consider  — and  therefore  should 
consider —  only  the  cases  " ym0 "  and  "y>0" .  Then  the  case  "y<0"  will 
lead  to  immediate  abortion,  which  is  a  better  alarm.  The  moral  is,  all 
other  things  being  equal,  we  should  choose  our  guards  as  strong  as 
possible.  ( End  of  note  2 .) 

The  remaining  refinement  is  easy,  if  only  a  correct  solution  is  wanted. 

For  efficiency,  the  following  refinement  contains  two  separate  improvements. 

"maintain  P,  decrease  y" : 

if  2 \y  ■*  y  y/2'>  x:«  x*x ; 

"maintain  P,  decrease  y" 

0  non  2\y  -*■  y:m  y-1 ; 
fi 

The  first  improvement  is  to  divide  the  task  into  two  cases,  one  of  which  gives 
a  possibly  large  decrease  in  y.  The  second  is  to  realize  that,  if 
y>0  and  2\y,  then  after  division  by  2  we  still  have  y>0  and  hence  we  may 
decrease  y  further. 
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Example  4 

[1,  p.67,  Ex.  7]  Given  an  integer  rfcO  and  a  function  f(i)  defined 
on  the  domain  Ozi<n>  establish 

R:  allsix^i  V  i  :0£i<n :/(-£)*£) 

Our  first  problem  solving  method,  "divide  and  conquer",  suggests  that  we 
look  for  predicates  P  and  Q  such  that  P  and  Q  ^  R.  In  the  previous 
examples,  we  have  found  the  invariant  P  by  weakening  R;  what  was  left 
became  Q.  We  now  take  the  opposite  approach:  we  shall  weaken  R  to  obtain 
Q;  what  is  left  will  be  P. 

Q:  allsix={  V  i:jzi<n:f(i)=6) 

P:  O^jsn  and  (  V  i:0z£<j 

Fortunately,  P  is  easily  established.  Our  program,  with  refinement,  follows. 

{P} 

"maintain  P,  establish  Q" 

"maintain  P,  establish  Q ": 
if  j*n  -*■  allsix true 
Q  0<n  ■*  if  fU)  +  6  +  allsix :■ false 

D/o')  “  6  -*■  j  :mj+l ;  "maintain  P,  establish  Q" 
fi 


fi 
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Exits 

Apparently,  the  problem  In  Example  3  has  been  cited  as  supporting  the  need 
for  intermediate  exits  from  loops.  One  of  Dijkstra's  purposes  in  presenting 
his  solution  is  to  remove  this  support.  But  one  example  is  not  proof;  those 
who  would  support  the  need  for  exits  may  prefer  Example  A,  or  some  other. 

The  argument  against  exits,  in  short,  is  clarity:  following  a  DO  that  contains 
an  exit  one  can  not  be  sure  that  all  guards  are  false.  The  argument  in  favour 
of  exits  is  efficiency:  arranging  that  all  guards  become  false  for  termination 
may  require  the  introduction  of  a  boolean  variable,  an  assignment,  and  many 
tests  that  would  be  unnecessary  using  an  exit  [9].  We  shall  not  take  a  side 
in  the  argument;  we  are  objecting  to  loops  with  or  without  exits.  But  we  shall 
show  the  relationship  between  recursive  refinement  and  exits. 

The  general  DO  construct  may  be  modelled  as  follows. 

"DO":  if  Bx  -+  SL i ;  "DO" 

0  B2  +  SL2 ;  "DO" 

0  ... 

D  B  +  SL  ;  "DO" 
n  n 

0  else  -*■  skip 
fi 

where  else  »  non  Q  i:B.).  (The  proof  that  the  above  is  equivalent  to  the  DO 
construct  is  presented  later.)  This  model  gives  us  a  way  of  translating 
programs  with  DO  constructs  into  programs  using  recursive  refinement.  But  the 
programs  so  constructed  are  not  necessarily  ones  to  be  proud  of ;  given  the 
different  facility,  we  may  construct  our  programs  differently.  Notice  that 
if  we  omit  the  recursive  "DO"  from  some  alternative,  we  have,  in  loop 
terminology,  an  intermediate  exit.  Programs  using  loops  and  exits  have  the 
curious  property  that  when  there  is  more  to  be  done,  one  says  nothing, but 
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when  there  Is  no  more  to  be  done,  one  says  something:  exit.  The  recursive 
version  is  more  straightforward;  when  there  is  more  to  be  done,  one  specifies 
it,  and  when  there  is  not,  one  says  nothing.  Unlike  the  DO  construct,  our 
decision  in  one  alternative  is  independent  of  our  decision  in  the  others;  we 
specify  further  (possibly  recursive)  action  precisely  in  those  alternatives 
where  further  action  is  needed. 

Deep  exits  have  been  proposed  as  a  means  of  exiting  several  nested  loops 
at  once.  The  arguments  for  and  against  are  the  same  as  for  intermediate 
exits:  efficiency  versus  clarity.  Once  again,  we  claim  to  provide  both.  A 
common  example  is  a  search  for  a  given  value  in  a  multi-dimensional  array. 

Given  integers  n^O  and  m^0t  and  an  array  or  function  a(i,j) 
defined  on  the  domain  0£i<n  and  0*g<m,  and  a  value  x,  establish  the 
following. 

RO:  Ozix&i 

R1 :  ix<n  =»  a(ix,jx)-x 

R2 :  ix**n  =>  non Cd  i :  Oai<n 0  j : <m:a(i  ,J ) »x) 

In  words:  ix  and  jx  are  to  indicate  a  position  of  value  x  in  the  array 
if  it  is  present;  setting  ix  to  w  will  Indicate  that  it  is  not. 

Our  solution  uses  two  invariants. 

PI:  O^ix-sn  and  nonQ  i:0£i<ix0^0stf  <m:a(i,j)**x) 
asserts  that  the  value  x  does  not  occur  prior  to  row  ix*  And 

P2:  Ozjx&n  and  nonG  j :0*j <jx:a(tx,j)“x) 
asserts  that  in  row  ix,  the  value  x  does  not  occur  prior  to  column  jx. 

Our  program  follows. 
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ix:-0 }  {PI } 

"maintain  PI  ,  establish  R1  or  £x-n"  {RO  and  R1  and  R2 } 


"maintain  PI,  establish  R1  or  ix*n": 
if  £x-n  ->  skip 
U  £r<n  ->  jx:«0 ;  {P2  } 

"maintain  PI  and  P2,  establish  PI  or  ix-n" 
fi 


"maintain  PI  and  P2,  establish  PI  or  ix-n": 
if  jx-m  -*■  ix:mix+l;iP2  may  be  destroyed} 

"maintain  PI,  establish  PI  or  ix-n"  {*»  P2} 


1 


jx«yn  •>  if  a(ix,jx)»x  ->  skip 

0  a(ixtjx)+x  ■+  jxi-jx+2; 


"maintain  PI  and  P2,  establish  PI  or^  ix-n" 


fi 


fi 


The  reader  is  invited  to  write  a  solution  using  DO  constructs,  stating 
all  invariants  and  subgoals  as  above,  and  compare  it  with  the  above.  Without 
an  exit,  the  solution  will  probably  involve  a  boolean  variable,  say  " found ", 
that  is  tested  many  times.  Perhaps  the  problem  as  stated  is  unfair;  it  may 
be  more  reasonable  to  represent  the  presence  of  value  x  by  a  boolean  variable 
than  by  the  expression  "£x<n".  If  so,  the  two  " skip "  statements  in  our 
solution  must  be  replaced  by  " found: * false"  and  " found :mtvue"  respectively, 
but  no  extra  testing  is  required. 
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Implementation 

In  general,  a  call  may  be  implemented  as  "stack  a  return  address,  then 
branch  to  the  start  of  a  refinement".  The  refinement  must  end  with  a 
return:  "unstack  a  return  address,  then  branch  to  it".  It  is  sometimes 
thought  that  stacking  is  unnecessary  if  recursion  is  prohibited.  The  usual 
FORTRAN  implementation,  for  example,  associates  with  each  subroutine  one 
location  for  storing  a  return  address.  But  these  locations  are  filled  and 
consulted  in  "last  in,  first  out"  order.  They  therefore  form  a  stack, 
although  its  elements  are  dispersed ;  there  is  no  advantage  in  dispersing  the 
stack.  Lack  of  recursion  tells  us  that  the  number  of  subroutines  (or 
refinements)  is  an  upper  bound  on  the  size  of  the  return  address  stack; 
often  the  program  structure  determines  a  much  smaller  upper  bound.  But  the 
general  need  for  a  stack  comes  with  the  call  and  refinement,  independent 
of  whether  there  are  recursive  calls. 

There  are  (at  least)  two  situations  in  which  stacking  activity  is 
unnecessary.  They  are  the  "last  action  call"  and  the  "only  call".  A 
statement  is  a  "last  action"  of  a  refinement  if  (a)  it  is  the  last  state¬ 
ment  of  the  refinement,  or  (b)  it  is  the  last  statement  of  an  alternative 
in  a  last  action  IF  statement.  A  last  action  call  may  be  implemented  simply 
as  a  branch.  This  is  independent  of  whether  the  call  is  recursive  [10]. 

A  call  for  a  refinement  is  an  "only  call"  if  all  other  calls  for  that 
refinement  are  last  action.  Assuming  that  last  action  calls  have  been 
implemented  as  branches,  we  may  Implement  an  only  call  as  a  branch,  and  the 
return  from  the  refinement  es  a  branch.  Or,  the  code  for  the  refinement 
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can  simply  replace  the  only  call.  The  latter  is  known  as  "opening" j  it  may 
be  done  even  if  the  replaced  call  is  not  an  only  call,  by  duplicating  the 
code  for  the  refinement  (if  one  so  wishes).  Once  again,  this  is  independent 
of  whether  the  replaced  call  is  recursive;  when  it  is,  this  is  known  as 
"unrolling". 

In  summary,  we  make  two  points.  The  first  is  that  recursion  is 
irrelevant  to  the  implementation  of  call  and  refinement;  it  adds  no  compli¬ 
cation.  The  second  is  that  our  programs,  implemented  as  described  above, 
are  as  efficient  as  those  using  DO,  and  sometimes  more  efficient  (see  the 
section  titled  "Exits").  In  particular,  none  of  the  examples  presented 
involves  any  stacking. 
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Solving  the  Semantic  Equations 

Given  a  statement  or  statement  list  St  we  consider  that  ve  understand  S 
when  we  know,  for  all  R ,  wp(S,  R) .  We  call  this  predicate  transformer 
the  semantics  of  S.  It  may  be  found  as  a  solution  to  the  semantic  equation 
for  St  as  given  in  the  section  titled  M Semantics".  If  S  is  not  recursive, 
the  equation  will  have  a  unique  solution  that  may  be  found,  assuming  we  know 
the  semantics  of  its  components,  by  an  appropriate  sequence  of  substitutions, 
compositions,  and  applications  of  basic  formulae.  If  5  is  recursive,  its 
semantic  equation  may  have  more  than  one  solution.  In  that  case,  wp(S,  i?) 
defined  as  the  strongest  solution,  i.e.,  that  solution  A  such  that,  if  B 
is  any  solution,  then  A**B.  The  existence  of  a  strongest  solution  follows 
from  the  existence  of  a  solution,  together  with  the  monotonicity  property: 
if  Q*R  then  wp(iS,  $)»*wp(S,  R) ;  in  words,  wp  preserves  implication.  The 
existence  of  a  solution  is  proved  constructively;  in  fact,  the  construction 
gives  us  the  strongest  solution.  This  section  concerns  that  construction. 

For  now,  we  confine  our  attention  to  direct  recursion.  With  this  re¬ 
striction,  a  semantic  equation  has  the  form  wp-f(wp).  The  strongest 
solution  may  be  found  as  the  limit  of  the  approximating  sequence 
wpo,  wpi,  wp2,  ...  defined  as  follows: 

WPO  m  F 

«i>t  ‘  f(wpt-i) 

where  "F"  is  the  predicate  that  is  everywhere  false;  we  shall  use  "T" 
for  the  predicate  that  is  everywhere  true.  The  sequence  is  monotonlcally 
weakening  (or,  more  precisely,  non-strengthening);  this  fact  follows  once 
again  from  the  monotonicity  property.  It  is  bounded  by  T.  Hence  a  limit 


is 


exists.  The  limit  is  unique;  this  fact  is  the  continuity  property,  proved 
in  [1,  ch.  9].  The  limit  may  be  expressed  as 
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vp  -  Q  i:  wp.) 

Note.  The  approach  we  are  taking  is  exactly  the  "least  fixed  point" 
approach  to  formal  semantics  taken  by  Scott  and  Strachey  [8].  For 
the  set  of  all  predicates  over  the  program  variables  forms  a  continuous 
lattice  whose  partial  ordering  is  implication.  The  limit  of  our 
approximating  sequence  is  a  "least  upper  bound"  if  we  identify  "bottom" 
with  "F"  and  "top"  with  "IT".  Each  wp .  that  approximates  wp  is 
the  exact  semantics  of  a  statement  S.  that  approximates  S.  If  S 
is  defined  (recursively)  as  "S:  ^ (S)",  then  the  S.  are  as 
follows: 

S  Q:  abort 
si: 

(End  of  note. ) 

Let  us  look  at  some  examples.  Our  first  one  is  inspired  by  Dijkstra's 
example  [1,  p.  76]  to  illustrate  that,  for  correct  execution,  if  two  guards 
are  true,  then  either  may  be  selected  regardless  of  the  past  history  of  the 
computation. 

"increment  x  by  an  arbitrary  amount": 

if  true  -*■  x:mx+l ;  "increment  x  by  an  arbitrary  amount" 

[|  true  -*■  skip 
fi 

wp  ("increment. .. ",  Ft)  -  wp("x:*r+7",  wp  ("increment. ..",  /?))  and  R 
wp0  -  F 

wpi  -  wp("x:-x+I",  F)  and  R 

-  F 
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We  have  immediate  convergence:  wp ("increment. .. ",  F)«F.  This  tells  us  that 
no  initial  state  will  guarantee  any  final  state,  i.e.,  not  even  termination  is 
guaranteed. 

Our  second  example  proves  the  statement  of  the  section  titled  "Problem 
Solving  Methods"  that  omitting  the  measurable  progress  is  futile. 

"establish  F":  if  B1  -  S 

A  B2  -  "establish  F" 
fi 

wp ("establish  F",  R) 

*  or  B2 )  and  (B1  =»  wp(S,  R))  and  ( B2  wp  ("establish  F",  R)) 

wp  o  *  F 

wpj  ■  (B1  or  B2 )  and  (B1  =>  wp  (5,  F))  and  (B2  =»  F) 

••  B1  and  non  B2  and  wp  (St  R) 
wp  £  "  ( B1  or  B2)  and  ( B1  =»  wp(5,  F) )  and 

(F2  =»  (BJ  and  non  B2  and  wp(F,  F))) 

■  B2  and  non  B2  and  wp(5,  R) 

We  have  converged  to  the  solution  wp ("establish  F",  F)  *  Bl  and  non  B2  and 
wp(5,  F) ,  which  implies  that  the  second  alternative  must  be  unnecessary. 

The  other  alternative  may  be  generalized  to  any  number  of  alternatives  without 
changing  this  conclusion. 

The  next  example  illustrates  that  measurable  progress  toward  the  goal  is 
sufficient  for  a  recursive  alternative. 

"maintain  t^O ,  establish  F": 
if  R  -►  skip 

[]  non  F  and  t>0  -*■  t:mt-l; 

"maintain  tstB,  establish  F" 


fi 
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wp  ("...",  R)  *  ( R  or_  (non  R  and  t>0))  and 
(7?  =»  wp ("sfcip",  R))  and 

((non  R  and  t>0 )  «=*  wp("t wp("...",  7?))) 

-  (7?  o£  t>0)  and  (non  7?  =»  wp("t wp("...",  7?))) 

By  finding  the  first  few  approximations,  we  are  led  to  the  formula 
wp^  -  G  3 :  0*7  :  * >3  arid  Rt ;  ^  . ) 

This  formula  may  be  proved  by  induction.  Thus 

wp  ("...",  R)  -  Hi  j  :  0*7* :  t>j  and  R^.^j) 

The  refinement  will  therefore  establish  7?  if  7?  can  be  established  by 
reducing  t.  The  proof  that  measurable  progress  is  sufficient  in  general 
will  not  be  given  here;  it  is  equivalent  to  DIJkstra's  proof  that  the 
execution  of  a  DO  construct  will  terminate  if  it  makes  measurable  progress 
on  each  repeated  execution. 

The  next  example  is  the  model  of  the  DO  construct  given  in  the  section 
titled  "Exits". 

"DO":  if  B\  +  SL i ;  "DO" 

D  BZ  -  sl2 ;  "DO" 

D  ... 

D  B  ■*  SL  ;  "DO" 
n  n 

D  else  ->  skip 

fi 

where  else* nonQ  i:Bi ).  In  this  example,  the  range  of  all  quantified 
variables  is  understood  to  be  the  integers  from  1  to  n,  unless  specified 


otherwise. 
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wp("DO",  R)  -  (G  i\B .)  or  else)  and 

QH:B.  =»  wp  {5L  . ,  wp("DO",  i?)))  and 
(else  =»  wpC'sHp",  /?)) 

-  (Vi:  5.  ■»  wp  (SI.,  wp("DO",  i?)))  and  {else  =*  R ) 

wp0  -  F 

wp^  -  C/i:B^  =»  wpCSL^,  > )  and  (else  »  i?) 

wp  ■  Cd  kik^Oivpfc) 

In  defining  the  semantics  of  the  repetitive  DO  construct,  Dijkstra  defines 
an  infinite  sequence  of  predicates  H q{R) ,  H\(R) ,  F2(F),...,  as  follows: 

H q(R)  m  else  and  /? 

F^(i?)  ■  (G  t  and  (Vi:B^  **  wp(5L^,  tffe_^(i?))  or  tfoO?) 

He  then  defines 

wp(DO,  i?)  -  G  k:k*0:Hk(R)) 

A  little  boolean  algebra  reveals  that  Hq{R)~wpi  and  that  the  recurrence 
relation  for  /^(F)  is  identical  to  the  one  for  wp^,.  The  two  sequences 
are  therefore  Identical,  except  for  a  shift  in  subscripts.  Since  wpg-F,  we 
could  redefine  wp*G  k:k>0:\rpk );  thus  we  have  proved  that  our  model  is 
semantically  equivalent  to  the  repetitive  DO.  The  advantage  of  basing  our 
approximating  sequence  on  wpo“F  is  that  this  base,  and  the  recurrence 
relation  wp^-f (wp^_^) ,  are  applicable  to  all  constructs,  whereas  the  E^fR) 
are  specific  to  DO.  The  advantage  of  basing  Hq(R)  as  Dijkstra  bases  it  is 
that,  thinking  operationally,  the  subscript  corresponds  to  the  number  of  times 
that  control  passes  through  the  loop. 


As  Dljkstra  has  pointed  out  [1,  p.17],  for  programming  we  are  not 
interested  in  the  complete  semantics  of  a  construct  S ;  that  is,  we  do 
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not  care  about  wp(S,  R)  for  all  R.  Ve  want  S  to  establish  a  particular 
predicate  P.  In  general,  to  find  wp(S,  P)  we  find  wp(<S,  R)  for  all  R 
and  then  substitute  P  for  R.  But  in  special  cases,  we  can  solve  directly 
for  wp(-S,  P).  Whenever  the  recursions  are  last  action  calls,  wp(S,  )  is 
applied  to  the  same  predicate  throughout  the  equation;  in  that  case,  we  can 
form  an  approximating  sequence  in  terms  of  the  particular  predicate  P.  In 
the  following  example,  although  the  recursion  is  not  a  last  action,  the 
equation  can  be  manipulated  into  the  required  form. 

"establish  r-n!": 
if  n-0+r:-l 
D  n>0-*n:~n-l ; 

"establish  r-n!"; 
n:-n+2 ; 
r:-r*n 
fi 

(This  program  is  not  recommended  for  its  efficiency;  it  serves  only  as  an 
example  for  solving  its  semantic  equation.)  As  the  choice  of  refinement 
name  states,  we  want  to  use  this  construct  to  establish  r-n!. 

wpC'establish  r-n!",  r-n!) 

-  (nzO)  and  (( n-0 )  **  wp("r:«I",  r-n!))  and  ((n>0)  =>  wp("n:-n-l", 

wpC’establish  r-n!",  wp("n:-n+l"»  wp("r:-r*n",  r-n!))))) 

-  (n^0)  and  (( n-0 )  =»  (1-n!))  and  (( n>0 )  wp("n:-n-2", 

wpC'establish  r-n!",  wp("n:-n+2",  r*n-n!)))) 

-  (n^O)  and  (( n>0 )  =*  wp("n:-n-l",  wpC'establish  r-n!",  r*(n+J)“(n+2) ! ))) 

-  (n*0)  and  (( n>0 )  =»  wp("n:-n-J",  wpC'establish  r-n!",  r-n!))) 
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The  approximating  sequence  may  now  be  formed,  yielding  the  expected  solution 
r&O. 


So  far,  we  have  confined  our  attention  to  direct  recursion.  The  equations 
for  indirect  recursions  can  sometimes  be  put  in  the  form  wp-f(wp)  by  sub¬ 
stitution.  The  program  that  searches  for  an  element  in  a  two-dimensional  array, 
presented  in  the  section  titled  "Exits",  is  such  an  example.  It  has  roughly 
the  following  form. 

D1 :  if  Bl+Sl 

C  B2+S2;  D2 

fi 

D2 :  if  B3+S3;  D1 
D  B4+S4;  D2 

fi 

By  substituting  for  wp (Dl,  R )  in  the  equation  for  wp(Z?2,  R)  we  eliminate 
the  indirection.  In  general,  when  such  a  substitution  is  impossible,  we  must 
solve  by  forming  several  approximating  sequences  simultaneously. 

The  predicate  transformer  wp(£,  R)  gives,  for  statement (s)  S  and  any 
post-condition  i?,  the  weakest  pre-condition  such  that  S  establishes  R. 
Dijkstra  also  introduces  the  "weakest  liberal  pre-condition"  predicate  trans¬ 
former  wlpOS,  i?),  which  gives  the  weakest  pre-condition  such  that  S  does  not 
establish  non  R.  If  S  is  deterministic,  then  wlp(5,  R)  ■  non  wp(5,  non  R) . 

In  general,  the  semantic  equations  for  wlp  are  as  follows. 
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wlp  ("afctp",  /?>-/? 
wlp("x:“E",  E)  -RxlmS 
wlp("5j ;52"t^)  ■  wlp  (5 1 ,  wlp(S2,  A)) 
wlp  (IF,  i?)  -  .  =*  wlp  (SL  . ,  i?)) 

When  the  equations  are  recursive,  wlp  Is  defined  as  the  weakest  solution. 

It  may  be  found  as  the  limit  of  the  approximating  sequence 
wlpo  "  T 
wlp^  -  f (wlp^_j ) 

Note.  Monotonicity  and  continuity  are  provable  for  wlp,  hence  a 
unique  limit  exists.  Once  again,  this  is  the  Scott-Strachey  "least 
fixed  point"  approach  [8]  if  we  turn  our  lattice  upside-down  and 
identify  "bottom"  with  "T"  and  "top"  with  "JF™.  Each  wlp^  that 
approximates  wlp  is  the  unique  solution  of  an  equation  for  a  state¬ 
ment  S.  that  approximates  S.  The  S.  are  the  same  for  wlp 
as  for  wp.  ( End  of  note.) 
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A  Final  Alternative 

According  to  the  semantic  equation  for  the  IF  construct,  every  IF 
contains  the  implicit  guarded  command  "else+abort" ;  the  condition 
is  a  simplification  of  "else  «*  wp {"abort",  R)" .  As  shown  in  the  previous 
section,  the  semantics  of  DO  are  those  of  IF  with  two  exceptions:  there  is 
an  implicit  recursion  after  each  explicit  alternative;  and  the  implicit 
guarded  command  is  "else+skip" .  Our  interest  in  this  section  is  in  the 
implicit  guarded  command. 

As  we  noted  in  Example  3,  our  programs,  using  IF,  are  more  robust  than 
those  using  DO.  The  extra  robustness  is  due  entirely  to  the  fact  that  the 
"else"  alternative  is  "abort"  in  IF,  and  "skip"  in  DO.  The  DO  could  have 
been  defined  with  extra  robustness  by  making  the  implicit  "else”  alternative 
"abort" ;  in  that  case  the  termination  condition  would  have  to  be  stated 
explicitly,  perhaps  by  the  guarded  command  "Bn+1+exit" •  The  IF  could  have 
been  defined  without  extra  robustness  by  making  the  implicit  "else" 
alternative  "skip";  this  would  be  similar  to  Algol's  one-tailed  "if . . . then. . .  . 

The  reader  who  has  compared  our  programming  examples  with  those  of  Dijkstra 
will  have  noticed  that  Dijkstra' 8  programs  are  more  compact.  There  are  two 
reasons  for  this:  one  is  that  the  call  and  refinement  statements  require  the 
introduction  of  names  for  portions  of  our  programs;  the  other  is  the  presence 
of  "skip"  alternatives.  Under  the  second  suggestion  of  the  preceeding  para¬ 
graph,  our  programs  would  be  more  compact.  Had  Dijkstra  chosen  to  add  robust¬ 
ness  by  making  his  guards  strong  and  including  an  "abort"  alternative,  his 
programs  would  be  less  compact.  The  tradeoff  is  clear:  robustness  versus 
compactness.  We  favour  robustness,  so  we  prefer  the  semantics  of  IF  as  Dijkstra 
has  defined  them.  But  we  point  out  the  alternative. 
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A  Notatlonal  Ideal 

We  assume  in  this  section  that  wp  is  the  only  predicate  transformer 
of  interest.  It  is  wp  that  defines  the  meaning  or  semantics  of  a  statement 
or  construct.  To  give  the  semantics  of  a  particular  statement  5,  one  must 
give  wp (5,  R )  for  all  predicates  R,  Thus  there  is  a  certain  asymmetry  in 
the  use  of  the  arguments.  As  a  first  suggestion,  consider  denoting  the 
weakest  pre-condition  such  that  5  establishes  R  by  "5(5)".  That  is,  we 
shall  consider  each  statement  to  be  a  predicate  transformer. 


In  the  semantic  equation  for  a  compound  statement  "51;  52",  it  is  pleasant 
to  write  the  component  statements  in  the  same  order  on  both  sides  of  the 
equation: 

(1)  "52;  52"  (2?)  -  52(52(5)) 

This  results  from  Dijkstra’s  "goal  oriented"  approach,  i.e.,  transforming 
post-conditions  to  pre-conditions,  together  with  our  traditional  prefix 
notation  for  functions.  But  when  the  compoaent  statements  are  assignments, 
it  is  annoying  to  see  them  occurring  in  reverse  order  as  subscripts.  This 
may  be  remedied  by  using  a  prefix  subscript: 

(2)  (5)  -  x:mER 
so  that 

"x:-S;  y:.D"V f) 

Having  made  these  suggestions,  we  are  struck  by  how  trivial,  and  purely 
cosmetic,  are  the  differences  between  the  left  and  right  sides  of  equations  (1) 
and  (2).  To  increase  the  similarity,  we  can  drop  the  parentheses,  since  we  are 
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dealing  with  only  unary,  prefix  operators.  We  are  struck  also  by  the  similarity 
between  Dijkstra's  notation  for  a  guarded  command,  and  the  implication  that  it 
gives  rise  to,  in  a  semantic  equation. 

There  is  no  point  in  having  two  notations  for  the  same  thing.  As  a 
notational  ideal,  we  suggest  that  each  statement  should  denote  its  meaning. 

A  programming  language  should  be  designed  so  that  one  need  not,  separately, 
give  the  semantic  equations.  Rather,  every  program  should  denote  its 


semantics. 
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Conclusion 

We  have  suggested  that  refinement  deserves  a  place  in  a  programming 
language,  to  allow  programs  to  retain  design  decisions  that  would  otherwise 
be  lost.  Given  refinement,  we  see  no  reason  to  enlarge  the  language  with 
a  special  rule  to  prohibit  recursion;  on  the  contrary,  recursive  refine¬ 
ment  is  a  more  flexible  programming  tool,  allowing  us  to  produce  clearer 
and  more  efficient  programs,  than  the  "do  guarded-command-set  od"  construct. 

There  are  (at  least)  two  reasons  that  recursion  has  been  considered  a 
difficult  programming  tool.  First,  it  has  been  tied  to  two  other  language 
issues:  parameters,  and  local  scope  (i.e.,  recursive  procedures).  It  is, 
however,  a  separable  concern.  Second,  almost  every  programming  text  explains 
recursion,  as  it  explains  all  language  constructs,  by  explaining  how  to  trace 
an  execution  according  to  some  implementation.  And  that  implementation  in¬ 
variably  Involves  a  stack,  even  though  a  stack  is  frequently  unnecessary. 

But  a  program  should  not  be  understood  in  terms  of  any  particular  implementation, 
and  cannot  be  understood  by  tracing  an  execution.  The  basis  of  our  under¬ 
standing  of  recursion,  or  of  loops,  must  be  the  principle  of  mathematical 
induction. 

It  is  sometimes  objected  that  an  average  person  cannot  be  expected  to 
understand  the  principle  of  induction,  or  to  apply  it  to  programming.  If 
that  were  true,  it  would  not  be  an  argument  against  the  use  of  induction  in 
programming,  but  against  the  use  of  average  people  as  programmers.  In  fact, 
average  people  understand  the  principle  perfectly  well,  although  informally. 

Given  a  positive  Integer,  and  enough  time,  an  average  person  believes  he 
can  count  from  1  to  the  given  Integer.  For  large  enough  integers,  that 
belief  is  not  based  on  the  experience  of  having  done  so,  but  on  an  implicit 
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understanding  of  induction.  And  finally,  we  remark  that  a  programmer  can 
often  use  a  result,  such  as  "measurable  progress  is  sufficient  for  recursion", 
whose  proof  is  an  induction,  rather  than  using  induction  directly. 

Our  programming  examples  were  chosen  from  among  those  that  Dijkstra 
used  [1]  to  exhibit  the  DO  construct.  The  ones  omitted  were  not  omitted 
to  hide  problems  that  arose;  on  the  contrary,  nothing  new  arose  in  them. 

The  reader  is  invited  to  come  to  this  happy  conclusion  for  himself  by 
trying  the  remaining  examples.  (Dijkstra' s  example  8  [1,  p.68]  is 
particularly  good.  Hint  1:  a  repeat. . .until. . .  would  have  improved 
Dijkstra '8  program,  as  in  our  example  2.  Hint  2:  there  is  an  error  in  one 
of  the  invariants.)  Only  through  practice  with  both  can  we  judge  the 
relative  merits  of  DO  and  recursive  refinement.  Initially,  the  latter 
will  be  at  a  disadvantage;  our  judgement  is,  of  course,  affected  by  what  we 
are  used  to,  and  most  of  us  (myself  included)  are  used  to  operational 
semantics  and  loops.  But  computer  programming  is  barely  30  years  old;  let 
us  not  be  too  set  in  our  ways  at  so  young  an  age. 
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Appendix 

This  appendix  contains  Dljkstra's  solutions  to  the  four  example  problems 
of  this  paper.  The  presentation  here  is  devoid  of  the  reasoning,  justifica¬ 
tions,  and  other  commentary  that  ought  to  accompany  these  solutions.  It  is 
Intended  only  as  a  reference,  and  not  as  a  substitute  for  [1]. 

Example  1  [1,  p.45] 

x:-X;  y:mY; 
do  x>y-*x:~x-y 
0  x<y-*y:my-x 
od ; 

print  (x) 

Example  2  [1,  p. 58] 
r:«a; 

do  rid*-dd:md;  do  ridd-+r : -r-dd ;  dd : -dd+dd  od 
od 

Example  3  [1,  p.66] 

x:mX ;  y:mY;  z:=l; 

do  y+0-* do  2\y-+y:-y/2;  x:~x*x  od;  y:my-l;  z:~z*x 
od 


Example  4  [1,  p.68] 

allsix:~true ; 

do  j+n  and  all8ix+all8ix:'*f(.i )■£:  od 
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PARAGRAPHING  PARSERS 

David  T.  Barnard,  March  1975  [M.Sc.  Thesis,  DCS,  1975] 

*  CSRG-53  QUERY  EXECUTION  AND  INDEX  SELECTION  FOR  RELATIONAL 

DATA  BASES 

J.H.  Gilles  Farley  and  Stewart  A.  Schuster,  March  1975 

CSRG-54  AN  ANNOTATED  BIBLIOGRAPHY  ON  COMPUTER 
PROGRAM  ENGINEERING 

J.V.  Guttag  (ed.).  Third  Edition,  April  1975 

CSRG-55  STRUCTURED  SUBSETS  OF  THE  PL/1  LANGUAGE 

Richard  C.  Holt  and  David  B.  Wortman,  May  1975 


CSRG-56  FEATURES  OF  A  CONCEPTUAL  SCHEMA 

D.  Tsichritzis,  June  1975  [Proceedings  Very  Large 
Data  Base  Conference,  1975] 

*  CSRG-57  MERLIN:  TOWARDS  AN  IDEAL  PROGRAMMING  LANGUAGE 
Eric  C.R.  Hehner,  July  1975 

CSRG-58  ON  THE  SEMANTICS  OF  THE  RELATIONAL  DATA  MODEL 
Hans  Albrecht  Schmid  and  J.  Richard  Swenson, 


July  1975  [Proceedings  of  the  ACM  SIGMOD  Conference, 
1975] 

CSRG-59 

THE  SPECIFICATION  AND  APPLICATION  TO  PROGRAMMING 

OF  ABSTRACT  DATA  TYPES 

John  V.  Guttag,  September  1975  [Ph.D.  Thesis,  DCS,  1975] 

CSRG-60 

NORMALIZATION  AND  FUNCTIONAL  DEPENDENCIES  IN  THE 
RELATIONAL  DATA  BASE  MODEL 

Phillip  Alan  Bernstein,  October  1975 
[Ph.D.  Thesis,  DCS,  1975] 

CSRG-61 

LSL:  A  LINK  AND  SELECTION  LANGUAGE 

D.  Tsichritzis,  November  1975  [Proceedings  ACM 
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COMPLEMENTARY  DEFINITIONS  OF  PROGRAMMING 

LANGUAGE  SEMANTICS 

James  E.  Donahue,  November  1975 
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AN  EXPERIMENTAL  EVALUATION  OF  CHESS  PLAYING 

HEURISTICS 

Lazio  Sugar,  December  1975  [M. Sc.  Thesis,  DCS,  1975] 
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A  VIRTUAL  MEMORY  SYSTEM  FOR  A  RELATIONAL 

ASSOCIATIVE  PROCESSOR 
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PERFORMANCE  EVALUATION  OF  A  RELATIONAL 

ASSOCIATIVE  PROCESSOR 

E.A.  Ozkarahan,  S.A.  Schuster,  and  K.C.  Sevcik, 
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EDITING  COMPUTER  ANIMATED  FILM 

Michael  D.  Tilson,  February  1976 
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SEMANTICS 

James  R.  Cordy,  March  1976  [M.Sc.  Thesis,  DCS,  1976] 
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A  SYNTHETIC  ENGLISH  QUERY  LANGUAGE  FOR  A 
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L. Kerschberg,  E.A.  Ozkarahan,  and  J.E.S.  Pacheco 
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L.  Kerschberg,  A.  Klug*  and  D.  Tsichritzis*  May  1976 
[Proceedings  Very  Large  Data  Base  Conference*  1976] 

CSRG-71  OPTIMIZATION  FEATURES  FOR  THE  ARCHITECTURE  OF  A 
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E.  A.  Ozkarahan  and  K.C.  Sevcik*  May  1976 
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CSRG-73  AN  ALGORITHMIC  APPROACH  TO  NORMALIZATION  OF 
RELATIONAL  DATA  BASE  SCHEMAS 
P.A.  Bernstein  and  C.  Beeri,  September  1976 
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E.A.  Ozkarahan  and  S.A.  Schuster*  October  1976 
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